Handle model provider timeouts and errors#4521
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4521 +/- ##
==========================================
+ Coverage 54.88% 56.91% +2.03%
==========================================
Files 307 355 +48
Lines 34522 38758 +4236
Branches 9871 10932 +1061
==========================================
+ Hits 18949 22061 +3112
- Misses 15554 16639 +1085
- Partials 19 58 +39
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
67b9ae1 to
a81e435
Compare
Electric Agents Mobile BuildLocal mobile checks ran for commit The EAS Android preview build was skipped because the |
samwillis
left a comment
There was a problem hiding this comment.
I found one issue that looks worth fixing before merge:
The new modelTimeout in packages/agents-runtime/src/pi-adapter.ts is armed once before agent.prompt() / agent.continue() and only cleared when the whole Pi agent run settles. That promise can include tool execution and multi-step model/tool loops, so a valid run with a slow tool or several turns can be aborted after the default 30s and reported as MODEL_PROVIDER_TIMEOUT, even if the model already responded successfully.
I’d scope the fallback to actual provider stream calls, or rely on Pi’s timeoutMs passthrough if that is per-provider-request. As written, long-running tools can become false provider timeouts.
Reviewed interactively with GPT.
Fixes #4520.
Summary
Verification